Skip to main content

Module 1: Data Selection Engine - select_data Form

← Back to Overview | Next: Data Processing → | Complete Reference

Module Overview​

Lines: 1326-1610
Importance: Tier 1 (Critical) - Core data selection engine
Purpose: Primary data collection module that fetches material data based on vendor or material selection criteria

Business Context​

Think of this module as a smart warehouse scanner that:

  • Identifies which materials need to be tracked based on selection criteria
  • Determines vendor relationships for each material
  • Collects safety stock information
  • Prepares the foundational data for all subsequent processing

Module Structure and Flow​

Detailed Line-by-Line Analysis​

Section 1: Initialization and Mode Detection (Lines 1326-1345)​

FORM select_data.
* Local Data declarations
DATA: lw_materials      TYPE ty_materials,
      lw_materials1     TYPE type_materials1,
      ...

What happens: Sets up local work areas and internal tables for data processing Analogy: Like setting up different containers and sorting boxes before starting to organize inventory

Section 2: Vendor Mode Processing (Lines 1346-1471)​

IF r_vendor EQ c_x.
  IF s_lifnr[] IS INITIAL.
    MESSAGE i000 WITH 'Vendor is mandatory'(040).
    LEAVE LIST-PROCESSING.

What happens:

  1. Lines 1346-1356: Validates that both vendor and plant are provided
  2. Lines 1360-1363: Calls get_data_marc to fetch material master data
  3. Lines 1366-1375: Selects purchasing info records (EORD table) that link vendors to materials

Key Business Logic:

Section 3: Material Mode Processing (Lines 1472-1539)​

ELSEIF r_mat EQ c_x.
  IF s_werks IS INITIAL.
    MESSAGE i000 WITH 'Plant is mandatory'(041).

What happens:

  1. Lines 1472-1478: Validates plant is provided (vendor is optional in material mode)
  2. Lines 1480-1483: Gets material master data
  3. Lines 1488-1520: Processes materials and their follow-up materials

Key Insight: In material mode, the program doesn't filter by vendor initially but collects all materials that match the criteria.

Section 4: Follow-up Material Processing (Lines 1407-1437 & 1492-1518)​

This is a complex but crucial business logic:

What this accomplishes: If Material A is being replaced by Material B, and Material B is being replaced by Material C, the system ensures:

  • Material A is tracked with its follow-up (B)
  • Material B is tracked with its follow-up (C)
  • No duplicate entries for Material B

Section 5: Subcontractor Data Collection (Lines 1561-1608)​

SELECT equk~matnr
       equk~werks
       equp~quote
       equp~lifnr
FROM equk
INNER JOIN equp
ON equk~qunum = equp~qunum

Purpose: Collects information about materials that are processed by subcontractors Business Value: Ensures subcontractor requirements are included in demand calculations

Section 6: Safety Stock Collection (Lines 1588-1605)​

SELECT werks
       matnr
       dispo
       eisbe
FROM marc
INTO TABLE t_safety_stk

Purpose: Retrieves safety stock quantities for each material-plant combination Why Important: Safety stock affects the first period's demand calculation

Data Structures Populated​

Table/StructurePurposeKey Fields
t_materialsMain material listmatnr, werks, lifnr, followup
t_vendorVendor informationlifnr, name1
t_equ_dataSubcontractor datamatnr, werks, quote, lifnr
t_safety_stkSafety stock levelswerks, matnr, eisbe

Error Handling and Validations​

  1. Line 1350: Vendor mandatory check in vendor mode
  2. Line 1354: Plant mandatory check in both modes
  3. Line 1475: Plant mandatory check in material mode
  4. Line 1550: Deletion of flagged materials (lvorm = 'X')

Performance Considerations​

  1. FOR ALL ENTRIES Pattern: Used extensively to avoid N+1 query problems
  2. SORT and BINARY SEARCH: Used for efficient lookups in follow-up material processing
  3. DELETE ADJACENT DUPLICATES: Ensures no duplicate materials in final result

Common Beginner Misconceptions​

❌ Wrong: "This module only selects materials"
✅ Correct: "This module builds the complete foundation including vendor relationships, follow-up materials, and supporting data"

❌ Wrong: "Vendor mode and material mode do the same thing"
✅ Correct: "Vendor mode filters by specific vendors first, material mode gets all materials then considers vendor relationships"

Integration Points​

Incoming: Called from main program after selection screen validation
Outgoing:

  • Calls get_data_marc for material master data
  • Populates global tables used by process_data
  • Sets up data foundation for build_output_table

Next Module Connection​

The t_materials table populated here becomes the driving table for the process_data form, where actual demand calculations occur.

← Back to Overview | Next: Data Processing → | Complete Reference